Network Configuration (NETCONF) is a protocol for network device configuration management. It is formulated by the NETCONF working group founded by the Internet Engineering Task Force (IETF) in the operations and management area, and is based on the eXtensible Markup Language (XML). The NETCONF protocol provides a mechanism for installing, maintaining, and deleting network devices. The NETCONF protocol uses XML data to encapsulate configuration data, and its protocol operations take place at the simple Remote Procedure Call (RPC) layer.
FIG. 1 shows the structure of the NETCONF protocol in the prior art. The NETCONF protocol is divided into four layers:
1. The transport protocol layer provides a communication path between the client and the server. NETCONF can be layered over any transport protocol such as the Blocks Extensible Exchange Protocol (BEEP), Secure Shell (SSH), Secure Socket Layer (SSL), and Console.
2. The RPC layer provides a simple, transport-independent framing mechanism for encoding RPCs.
3. The operations layer defines a set of base operations invoked as RPC methods with XML-encoded parameters.
4. The content layer has not been defined.
FIG. 2 is a flowchart of sending notification information through the NETCONF protocol in the prior art.
In the XML Path Language (XPath), if the path begins with a slash (/), the path is an absolute path to an element. For example:
For the following XML file:
<AAA> <BBB/> <CCC/> <BBB/> <BBB/> <DDD>  <BBB/> </DDD> <CCC/> </AAA>
“Xpath:/AAA/DDD/BBB” indicates that all sub-elements of the sub-element “DDD” of “AAA” are selected.
The prior NETCONF protocol provides a mechanism of an asynchronous notification information service, including the capability operations required for the device to support the service.
The prior format of the notification sent through NETCONF is exemplified below:
<?xml version=“1.0” encoding=“UTF-8”?> <notification xmlns=“urn:ietf:params:xml:ns:netconf:notification:1.0”>  <data xmlns=“http://example.com/event/1.0”>   <severity>notice</severity>   <eventClasses><configuration/><audit/></eventClasses>   <sequenceNumber>2</sequenceNumber>   <dateAndTime>2000-01-12T12:13:14Z</dateAndTime>   <user>Fred Flinstone</user>   <operation>    <edit-config>     <target>     <running/>     </target>     <edit-config>      <top xmlns=“http://example.com/schema/1.2/config”>       <interfaces>        <interface>         <name>Ethernet0/0</name>         <mtu>1500</mtu>        </interface>       </interfaces>      </top>    </edit-config>   </operation>  </event>  </data> </notification>
FIG. 3 shows a data structure of a notification in the prior art. The prior NETCONF protocol does not define the content in the notification, and includes only one “data” element which may be of any type. In this “data” element, any type of data can be written, and the amount of data is not limited. The XML Schema is as follows:
<!-- <Event> operation --><xs:complexType name=“NotificationType”> <xs:sequence>  <xs:element name=“data” type=“netconf:dataInlineType”/> </xs:sequence></xs:complexType><xs:element name=“notification” type=“NotificationType”/>
In the process of implementing the present invention, the inventor discovers that the data model of the notification is not abstract and that the public data is not summarized, which affects interworking. For example, Network Management System (NMS) A needs to obtain the element “EventName” from the notification, and use it as a condition for querying the alarm/event on the NMS; device B does not report “EventName” in the notification, but identifies the alarm/event in other modes. When the data reported by B is processed on A, problems may occur for lack of the keyword field.
The prior notification uses the operation (such as “edit-contig”) that triggers the alarm/event and its element (such as “interface”) to describe the alarm/event object, for example:
<operation> <edit-config>  <target>  <running>  </target>  <edit-config>   <top xmlns=“http://example.com/schema/1.2/config”>    <interfaces>     <interface>      <name>Ethernet0/0</name>      <mtu>1500</mtu>     </interface>    </interfaces>   </top> </edit-config></operation>
Therefore, too many XML tags are introduced to identify the interface Ethernet0/0, and a single notification packet is too big, which affects the data transmission efficiency.